Monorepo最佳实践之Yarn Workspaces

Yarn Workspaces（工作空间/工作区，本文使用工作空间这一名称）是Yarn提供的Monorepo依赖管理机制，从Yarn 1.0开始默认支持，用于在代码仓库的根目录下管理多个project的依赖。 Yarn Workspaces的目标是使使用Monorepo(Monorepository)变得简单，以一种更具声明性的方式处理yarn link的主要使用场景。简而言之，它们允许多个项目共存在同一个代码库中，并相互交叉引用，并且保证一个项目源代码的任何修改都会立即应用到其他项目中。

无论是维护npm包还是开发大型前端系统，都存在在不同功能模块中管理着多个功能相近的包，或者这些包之间存在依赖关系的场景。如果将这些包拆分在不同仓库里，那么面临要跨多个包进行更改时，工作会非常繁琐和复杂。 重复安装、管理繁琐的缺点从npm package诞生起便一直存在，node_modules hell就是该问题的集中体现。

为了简化流程，很多大型项目采用了Monorepo的做法，即把所有的包放在一个仓库中管理

Babel、React、Vue、Jest等都使用了monorepo的管理方式。

Menorepo的优点是可以在一个仓库里维护多个package，可统一构建，跨package调试、依赖管理、版本发布都十分方便，搭配工具还能统一生成CHANGELOG； 代价是即使只开发其中一个package也需要安装整个项目的依赖。以jest为例，其Monorepo代码结构为：

在以Monorepo为代码组织方式的项目中，依赖管理的规模和复杂度均有不小的提升（这也不难理解，随着”数量“的增加，任何小的问题都会变得复杂）。 如何减少依赖重复安装？如何优雅实现跨目录代码共享？如何对依赖版本进行统一管理以避免版本冲突？ 所以这些问题都可以借助Yarn Workspaces来解决！ Yarn官方对于Yarn Workspaces的使用时机（Why would you want to do this?）是这样描述的：

在Workspace作用空间下的任何一个目录下执行yarn命令都会安装整个Workspace的依赖。

首先，需要确保项目中安装有yarn，怎么安装呢？当然是借助npm了（当未来某一天node.js同时内置了npm和yarn时就不需要这么麻烦了）。

然后在项目根目录的package.json中增加如下配置：

Note that the private: true is required! Workspaces are not meant to be published, so we’ve added this safety measure to make sure that nothing can accidentally expose them. 注意：private: true配置是必需的！工作区并不意味着要被发布，所以需要添加了这个安全措施，以确保不会发布到npm仓库。

之后，创建两个名为app1和app2的子文件夹。在其中的每个文件中，分别配置如下package.json文件： app1/package.json:

app2/package.json:

最后，就可以开始在workspace下开发app1、app2项目了。安装项目依赖时，为了方便后续开发可以在项目根目录执行yarn install，这样就会安装整个Workspace的依赖，后续无论是在app1还是app2都不需要重新安装。 执行完yarn i之后上述示例workspace的目录结构为：

使用yarn workspaces info [--json]命令可以获得整个workspace的目录结构：

说明：

命令格式：

作用：在指定的workspace下执行command，即command作用域为某个workspace。示例：

作用：此命令将显示当前项目的工作空间依赖关系树。示例：

作用：将在每个工作区中运行所选择的Yarn命令，即遍历所有workspace执行command命令，示例：

注意：在Yarn 2.x中删除了yarn workspaces info指令

2021年9月6号，yarn发布最新版本：2.4.3。在该版本中增加了几个跟workspace相关的CLI。

要使用此命令，请先安装workspace-tools插件：yarn plugin import workspace-tools

作用：安装单个工作区及其依赖项。

要使用此命令，请先安装workspace-tools插件：yarn plugin import workspace-tools

作用：在所有工作空间上运行command命令(有点类似Yarn 1.x中的yarn workspaces)。示例：

注意：需要在workspace-root下执行。 作用：列出所有可用的工作区。示例：

Yarn Workspace的典型实践便是在workspace之间的互相link引用，其省去了繁琐的 npm 发布步骤，本地引用基于yarn link软链到本地source code，代码的修改会实时在引用它的workspace中生效。接下来将通过一个实例来展示Yarn Workspace的强大之处，示例代码已上传至github。

demo项目的主要实践有：

代码目录：

在workspace root下有三个workspace：app1、app2、hello-world，其中app1和app2是create-react-app生成的react脚手架项目，hello-world是一个简单的react组件。三个workspace的package.json配置为：

根目录的package.json配置启用了yarn workspace：

通过yarn workspaces info --json查看当前worktree：

在Yarn Workspaces作用域下，workspace的互相引用变更简单起来，现在要在app1中使用components/hello-wrold组件，只需两步即可完成。

安装完毕后再使用yarn workspaces info --json查看当前worktree：

可以发现app1的workspaceDependencies依赖增加了一项：hello-world。

针对Yarn Workspaces存在的上述问题，推荐一套项目级别的实施规范。以利用其长处，避免其短处。

在需要本地依赖的组件的package.json中设置private：true，目的是防止其被误上传至 npm 远程仓库。强制限定只能通过本地源码link的方式引用，这样就可以有效避免问题4。

即各个workspace的pakcage.json中不再声明dependencies、devDependencies，依赖的注册全部收敛到workspace-root的package.json中。 对于新的项目可以在一开始就只使用yarn -W add [package] [--dev]进行安装，对于历史项目可以手工修改各workspace的package.json，将依赖剪切到根目录的package.json里。 这样做的好处是统一各个子workspace的依赖版本，避免同一依赖安装不同版本，保持整个worktree下项目里依赖版本的统一，并在各workspace间共享依赖。 对于全局共享依赖带来的项目初始化安装时间的增加，是可以接受的，因为只是首次安装耗时长而已，后续因为有缓存，安装时间将大大缩减。

所有新增的依赖需要通过yarn -W add [package] [--dev]进行安装，这一条可以认识是对第二条规范的补充。

yarn.lock是yarn依赖版本控制的基础，在全局共享依赖的框架下，yarn.lock文件的维护变得尤其重要。保证提交是为了确保新增依赖能够纳入到yarn版本管控中，正确解决冲突则是确保依赖版本的唯一性、统一性。

eslint和prettier配置已经成为规范项目代码的标配，既然是配置当然要在整个Workspace范围内保持统一。

这是对规范5补充，确保全局代码规范能够生效； 也能让开发者方便查看yarn workspace link的Packages

Yarn 1 Workspace Yarn 2 Workspace monorepo-lerna-yarn-workspaces 应用级 Monorepo 优化方案